home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / bison121.lha / bison-1.21 / bison.info-4 (.txt) < prev    next >
GNU Info File  |  1993-04-13  |  51KB  |  1,004 lines

  1. This is Info file bison.info, produced by Makeinfo-1.52 from the input
  2. file ./bison.texinfo.
  3.    This file documents the Bison parser generator.
  4.    Copyright (C) 1988, 1989, 1990, 1991, 1992 Free Software Foundation,
  5.    Permission is granted to make and distribute verbatim copies of this
  6. manual provided the copyright notice and this permission notice are
  7. preserved on all copies.
  8.    Permission is granted to copy and distribute modified versions of
  9. this manual under the conditions for verbatim copying, provided also
  10. that the sections entitled "GNU General Public License" and "Conditions
  11. for Using Bison" are included exactly as in the original, and provided
  12. that the entire resulting derived work is distributed under the terms
  13. of a permission notice identical to this one.
  14.    Permission is granted to copy and distribute translations of this
  15. manual into another language, under the above conditions for modified
  16. versions, except that the sections entitled "GNU General Public
  17. License", "Conditions for Using Bison" and this permission notice may be
  18. included in translations approved by the Free Software Foundation
  19. instead of in the original English.
  20. File: bison.info,  Node: Mystery Conflicts,  Next: Stack Overflow,  Prev: Reduce/Reduce,  Up: Algorithm
  21. Mysterious Reduce/Reduce Conflicts
  22. ==================================
  23.    Sometimes reduce/reduce conflicts can occur that don't look
  24. warranted.  Here is an example:
  25.      %token ID
  26.      
  27.      %%
  28.      def:    param_spec return_spec ','
  29.              ;
  30.      param_spec:
  31.                   type
  32.              |    name_list ':' type
  33.              ;
  34.      return_spec:
  35.                   type
  36.              |    name ':' type
  37.              ;
  38.      type:        ID
  39.              ;
  40.      name:        ID
  41.              ;
  42.      name_list:
  43.                   name
  44.              |    name ',' name_list
  45.              ;
  46.    It would seem that this grammar can be parsed with only a single
  47. token of look-ahead: when a `param_spec' is being read, an `ID' is a
  48. `name' if a comma or colon follows, or a `type' if another `ID'
  49. follows.  In other words, this grammar is LR(1).
  50.    However, Bison, like most parser generators, cannot actually handle
  51. all LR(1) grammars.  In this grammar, two contexts, that after an `ID'
  52. at the beginning of a `param_spec' and likewise at the beginning of a
  53. `return_spec', are similar enough that Bison assumes they are the same.
  54. They appear similar because the same set of rules would be active--the
  55. rule for reducing to a `name' and that for reducing to a `type'.  Bison
  56. is unable to determine at that stage of processing that the rules would
  57. require different look-ahead tokens in the two contexts, so it makes a
  58. single parser state for them both.  Combining the two contexts causes a
  59. conflict later.  In parser terminology, this occurrence means that the
  60. grammar is not LALR(1).
  61.    In general, it is better to fix deficiencies than to document them.
  62. But this particular deficiency is intrinsically hard to fix; parser
  63. generators that can handle LR(1) grammars are hard to write and tend to
  64. produce parsers that are very large.  In practice, Bison is more useful
  65. as it is now.
  66.    When the problem arises, you can often fix it by identifying the two
  67. parser states that are being confused, and adding something to make them
  68. look distinct.  In the above example, adding one rule to `return_spec'
  69. as follows makes the problem go away:
  70.      %token BOGUS
  71.      ...
  72.      %%
  73.      ...
  74.      return_spec:
  75.                   type
  76.              |    name ':' type
  77.              /* This rule is never used.  */
  78.              |    ID BOGUS
  79.              ;
  80.    This corrects the problem because it introduces the possibility of an
  81. additional active rule in the context after the `ID' at the beginning of
  82. `return_spec'.  This rule is not active in the corresponding context in
  83. a `param_spec', so the two contexts receive distinct parser states.  As
  84. long as the token `BOGUS' is never generated by `yylex', the added rule
  85. cannot alter the way actual input is parsed.
  86.    In this particular example, there is another way to solve the
  87. problem: rewrite the rule for `return_spec' to use `ID' directly
  88. instead of via `name'.  This also causes the two confusing contexts to
  89. have different sets of active rules, because the one for `return_spec'
  90. activates the altered rule for `return_spec' rather than the one for
  91. `name'.
  92.      param_spec:
  93.                   type
  94.              |    name_list ':' type
  95.              ;
  96.      return_spec:
  97.                   type
  98.              |    ID ':' type
  99.              ;
  100. File: bison.info,  Node: Stack Overflow,  Prev: Mystery Conflicts,  Up: Algorithm
  101. Stack Overflow, and How to Avoid It
  102. ===================================
  103.    The Bison parser stack can overflow if too many tokens are shifted
  104. and not reduced.  When this happens, the parser function `yyparse'
  105. returns a nonzero value, pausing only to call `yyerror' to report the
  106. overflow.
  107.    By defining the macro `YYMAXDEPTH', you can control how deep the
  108. parser stack can become before a stack overflow occurs.  Define the
  109. macro with a value that is an integer.  This value is the maximum number
  110. of tokens that can be shifted (and not reduced) before overflow.  It
  111. must be a constant expression whose value is known at compile time.
  112.    The stack space allowed is not necessarily allocated.  If you
  113. specify a large value for `YYMAXDEPTH', the parser actually allocates a
  114. small stack at first, and then makes it bigger by stages as needed.
  115. This increasing allocation happens automatically and silently.
  116. Therefore, you do not need to make `YYMAXDEPTH' painfully small merely
  117. to save space for ordinary inputs that do not need much stack.
  118.    The default value of `YYMAXDEPTH', if you do not define it, is 10000.
  119.    You can control how much stack is allocated initially by defining the
  120. macro `YYINITDEPTH'.  This value too must be a compile-time constant
  121. integer.  The default is 200.
  122. File: bison.info,  Node: Error Recovery,  Next: Context Dependency,  Prev: Algorithm,  Up: Top
  123. Error Recovery
  124. **************
  125.    It is not usually acceptable to have a program terminate on a parse
  126. error.  For example, a compiler should recover sufficiently to parse the
  127. rest of the input file and check it for errors; a calculator should
  128. accept another expression.
  129.    In a simple interactive command parser where each input is one line,
  130. it may be sufficient to allow `yyparse' to return 1 on error and have
  131. the caller ignore the rest of the input line when that happens (and
  132. then call `yyparse' again).  But this is inadequate for a compiler,
  133. because it forgets all the syntactic context leading up to the error.
  134. A syntax error deep within a function in the compiler input should not
  135. cause the compiler to treat the following line like the beginning of a
  136. source file.
  137.    You can define how to recover from a syntax error by writing rules to
  138. recognize the special token `error'.  This is a terminal symbol that is
  139. always defined (you need not declare it) and reserved for error
  140. handling.  The Bison parser generates an `error' token whenever a
  141. syntax error happens; if you have provided a rule to recognize this
  142. token in the current context, the parse can continue.
  143.    For example:
  144.      stmnts:  /* empty string */
  145.              | stmnts '\n'
  146.              | stmnts exp '\n'
  147.              | stmnts error '\n'
  148.    The fourth rule in this example says that an error followed by a
  149. newline makes a valid addition to any `stmnts'.
  150.    What happens if a syntax error occurs in the middle of an `exp'?  The
  151. error recovery rule, interpreted strictly, applies to the precise
  152. sequence of a `stmnts', an `error' and a newline.  If an error occurs in
  153. the middle of an `exp', there will probably be some additional tokens
  154. and subexpressions on the stack after the last `stmnts', and there will
  155. be tokens to read before the next newline.  So the rule is not
  156. applicable in the ordinary way.
  157.    But Bison can force the situation to fit the rule, by discarding
  158. part of the semantic context and part of the input.  First it discards
  159. states and objects from the stack until it gets back to a state in
  160. which the `error' token is acceptable.  (This means that the
  161. subexpressions already parsed are discarded, back to the last complete
  162. `stmnts'.)  At this point the `error' token can be shifted.  Then, if
  163. the old look-ahead token is not acceptable to be shifted next, the
  164. parser reads tokens and discards them until it finds a token which is
  165. acceptable.  In this example, Bison reads and discards input until the
  166. next newline so that the fourth rule can apply.
  167.    The choice of error rules in the grammar is a choice of strategies
  168. for error recovery.  A simple and useful strategy is simply to skip the
  169. rest of the current input line or current statement if an error is
  170. detected:
  171.      stmnt: error ';'  /* on error, skip until ';' is read */
  172.    It is also useful to recover to the matching close-delimiter of an
  173. opening-delimiter that has already been parsed.  Otherwise the
  174. close-delimiter will probably appear to be unmatched, and generate
  175. another, spurious error message:
  176.      primary:  '(' expr ')'
  177.              | '(' error ')'
  178.              ...
  179.              ;
  180.    Error recovery strategies are necessarily guesses.  When they guess
  181. wrong, one syntax error often leads to another.  In the above example,
  182. the error recovery rule guesses that an error is due to bad input
  183. within one `stmnt'.  Suppose that instead a spurious semicolon is
  184. inserted in the middle of a valid `stmnt'.  After the error recovery
  185. rule recovers from the first error, another syntax error will be found
  186. straightaway, since the text following the spurious semicolon is also
  187. an invalid `stmnt'.
  188.    To prevent an outpouring of error messages, the parser will output
  189. no error message for another syntax error that happens shortly after
  190. the first; only after three consecutive input tokens have been
  191. successfully shifted will error messages resume.
  192.    Note that rules which accept the `error' token may have actions, just
  193. as any other rules can.
  194.    You can make error messages resume immediately by using the macro
  195. `yyerrok' in an action.  If you do this in the error rule's action, no
  196. error messages will be suppressed.  This macro requires no arguments;
  197. `yyerrok;' is a valid C statement.
  198.    The previous look-ahead token is reanalyzed immediately after an
  199. error.  If this is unacceptable, then the macro `yyclearin' may be used
  200. to clear this token.  Write the statement `yyclearin;' in the error
  201. rule's action.
  202.    For example, suppose that on a parse error, an error handling
  203. routine is called that advances the input stream to some point where
  204. parsing should once again commence.  The next symbol returned by the
  205. lexical scanner is probably correct.  The previous look-ahead token
  206. ought to be discarded with `yyclearin;'.
  207.    The macro `YYRECOVERING' stands for an expression that has the value
  208. 1 when the parser is recovering from a syntax error, and 0 the rest of
  209. the time.  A value of 1 indicates that error messages are currently
  210. suppressed for new syntax errors.
  211. File: bison.info,  Node: Context Dependency,  Next: Debugging,  Prev: Error Recovery,  Up: Top
  212. Handling Context Dependencies
  213. *****************************
  214.    The Bison paradigm is to parse tokens first, then group them into
  215. larger syntactic units.  In many languages, the meaning of a token is
  216. affected by its context.  Although this violates the Bison paradigm,
  217. certain techniques (known as "kludges") may enable you to write Bison
  218. parsers for such languages.
  219. * Menu:
  220. * Semantic Tokens::   Token parsing can depend on the semantic context.
  221. * Lexical Tie-ins::   Token parsing can depend on the syntactic context.
  222. * Tie-in Recovery::   Lexical tie-ins have implications for how
  223.                         error recovery rules must be written.
  224.    (Actually, "kludge" means any technique that gets its job done but is
  225. neither clean nor robust.)
  226. File: bison.info,  Node: Semantic Tokens,  Next: Lexical Tie-ins,  Up: Context Dependency
  227. Semantic Info in Token Types
  228. ============================
  229.    The C language has a context dependency: the way an identifier is
  230. used depends on what its current meaning is.  For example, consider
  231. this:
  232.      foo (x);
  233.    This looks like a function call statement, but if `foo' is a typedef
  234. name, then this is actually a declaration of `x'.  How can a Bison
  235. parser for C decide how to parse this input?
  236.    The method used in GNU C is to have two different token types,
  237. `IDENTIFIER' and `TYPENAME'.  When `yylex' finds an identifier, it
  238. looks up the current declaration of the identifier in order to decide
  239. which token type to return: `TYPENAME' if the identifier is declared as
  240. a typedef, `IDENTIFIER' otherwise.
  241.    The grammar rules can then express the context dependency by the
  242. choice of token type to recognize.  `IDENTIFIER' is accepted as an
  243. expression, but `TYPENAME' is not.  `TYPENAME' can start a declaration,
  244. but `IDENTIFIER' cannot.  In contexts where the meaning of the
  245. identifier is *not* significant, such as in declarations that can
  246. shadow a typedef name, either `TYPENAME' or `IDENTIFIER' is
  247. accepted--there is one rule for each of the two token types.
  248.    This technique is simple to use if the decision of which kinds of
  249. identifiers to allow is made at a place close to where the identifier is
  250. parsed.  But in C this is not always so: C allows a declaration to
  251. redeclare a typedef name provided an explicit type has been specified
  252. earlier:
  253.      typedef int foo, bar, lose;
  254.      static foo (bar);        /* redeclare `bar' as static variable */
  255.      static int foo (lose);   /* redeclare `foo' as function */
  256.    Unfortunately, the name being declared is separated from the
  257. declaration construct itself by a complicated syntactic structure--the
  258. "declarator".
  259.    As a result, the part of Bison parser for C needs to be duplicated,
  260. with all the nonterminal names changed: once for parsing a declaration
  261. in which a typedef name can be redefined, and once for parsing a
  262. declaration in which that can't be done.  Here is a part of the
  263. duplication, with actions omitted for brevity:
  264.      initdcl:
  265.                declarator maybeasm '='
  266.                init
  267.              | declarator maybeasm
  268.              ;
  269.      
  270.      notype_initdcl:
  271.                notype_declarator maybeasm '='
  272.                init
  273.              | notype_declarator maybeasm
  274.              ;
  275. Here `initdcl' can redeclare a typedef name, but `notype_initdcl'
  276. cannot.  The distinction between `declarator' and `notype_declarator'
  277. is the same sort of thing.
  278.    There is some similarity between this technique and a lexical tie-in
  279. (described next), in that information which alters the lexical analysis
  280. is changed during parsing by other parts of the program.  The
  281. difference is here the information is global, and is used for other
  282. purposes in the program.  A true lexical tie-in has a special-purpose
  283. flag controlled by the syntactic context.
  284. File: bison.info,  Node: Lexical Tie-ins,  Next: Tie-in Recovery,  Prev: Semantic Tokens,  Up: Context Dependency
  285. Lexical Tie-ins
  286. ===============
  287.    One way to handle context-dependency is the "lexical tie-in": a flag
  288. which is set by Bison actions, whose purpose is to alter the way tokens
  289. are parsed.
  290.    For example, suppose we have a language vaguely like C, but with a
  291. special construct `hex (HEX-EXPR)'.  After the keyword `hex' comes an
  292. expression in parentheses in which all integers are hexadecimal.  In
  293. particular, the token `a1b' must be treated as an integer rather than
  294. as an identifier if it appears in that context.  Here is how you can do
  295.      %{
  296.      int hexflag;
  297.      %}
  298.      %%
  299.      ...
  300.      expr:   IDENTIFIER
  301.              | constant
  302.              | HEX '('
  303.                      { hexflag = 1; }
  304.                expr ')'
  305.                      { hexflag = 0;
  306.                         $$ = $4; }
  307.              | expr '+' expr
  308.                      { $$ = make_sum ($1, $3); }
  309.              ...
  310.              ;
  311.      
  312.      constant:
  313.                INTEGER
  314.              | STRING
  315.              ;
  316. Here we assume that `yylex' looks at the value of `hexflag'; when it is
  317. nonzero, all integers are parsed in hexadecimal, and tokens starting
  318. with letters are parsed as integers if possible.
  319.    The declaration of `hexflag' shown in the C declarations section of
  320. the parser file is needed to make it accessible to the actions (*note
  321. The C Declarations Section: C Declarations.).  You must also write the
  322. code in `yylex' to obey the flag.
  323. File: bison.info,  Node: Tie-in Recovery,  Prev: Lexical Tie-ins,  Up: Context Dependency
  324. Lexical Tie-ins and Error Recovery
  325. ==================================
  326.    Lexical tie-ins make strict demands on any error recovery rules you
  327. have.  *Note Error Recovery::.
  328.    The reason for this is that the purpose of an error recovery rule is
  329. to abort the parsing of one construct and resume in some larger
  330. construct.  For example, in C-like languages, a typical error recovery
  331. rule is to skip tokens until the next semicolon, and then start a new
  332. statement, like this:
  333.      stmt:   expr ';'
  334.              | IF '(' expr ')' stmt { ... }
  335.              ...
  336.              error ';'
  337.                      { hexflag = 0; }
  338.              ;
  339.    If there is a syntax error in the middle of a `hex (EXPR)'
  340. construct, this error rule will apply, and then the action for the
  341. completed `hex (EXPR)' will never run.  So `hexflag' would remain set
  342. for the entire rest of the input, or until the next `hex' keyword,
  343. causing identifiers to be misinterpreted as integers.
  344.    To avoid this problem the error recovery rule itself clears
  345. `hexflag'.
  346.    There may also be an error recovery rule that works within
  347. expressions.  For example, there could be a rule which applies within
  348. parentheses and skips to the close-parenthesis:
  349.      expr:   ...
  350.              | '(' expr ')'
  351.                      { $$ = $2; }
  352.              | '(' error ')'
  353.              ...
  354.    If this rule acts within the `hex' construct, it is not going to
  355. abort that construct (since it applies to an inner level of parentheses
  356. within the construct).  Therefore, it should not clear the flag: the
  357. rest of the `hex' construct should be parsed with the flag still in
  358. effect.
  359.    What if there is an error recovery rule which might abort out of the
  360. `hex' construct or might not, depending on circumstances?  There is no
  361. way you can write the action to determine whether a `hex' construct is
  362. being aborted or not.  So if you are using a lexical tie-in, you had
  363. better make sure your error recovery rules are not of this kind.  Each
  364. rule must be such that you can be sure that it always will, or always
  365. won't, have to clear the flag.
  366. File: bison.info,  Node: Debugging,  Next: Invocation,  Prev: Context Dependency,  Up: Top
  367. Debugging Your Parser
  368. *********************
  369.    If a Bison grammar compiles properly but doesn't do what you want
  370. when it runs, the `yydebug' parser-trace feature can help you figure
  371. out why.
  372.    To enable compilation of trace facilities, you must define the macro
  373. `YYDEBUG' when you compile the parser.  You could use `-DYYDEBUG=1' as
  374. a compiler option or you could put `#define YYDEBUG 1' in the C
  375. declarations section of the grammar file (*note The C Declarations
  376. Section: C Declarations.).  Alternatively, use the `-t' option when you
  377. run Bison (*note Invoking Bison: Invocation.).  We always define
  378. `YYDEBUG' so that debugging is always possible.
  379.    The trace facility uses `stderr', so you must add
  380. `#include <stdio.h>' to the C declarations section unless it is already
  381. there.
  382.    Once you have compiled the program with trace facilities, the way to
  383. request a trace is to store a nonzero value in the variable `yydebug'.
  384. You can do this by making the C code do it (in `main', perhaps), or you
  385. can alter the value with a C debugger.
  386.    Each step taken by the parser when `yydebug' is nonzero produces a
  387. line or two of trace information, written on `stderr'.  The trace
  388. messages tell you these things:
  389.    * Each time the parser calls `yylex', what kind of token was read.
  390.    * Each time a token is shifted, the depth and complete contents of
  391.      the state stack (*note Parser States::.).
  392.    * Each time a rule is reduced, which rule it is, and the complete
  393.      contents of the state stack afterward.
  394.    To make sense of this information, it helps to refer to the listing
  395. file produced by the Bison `-v' option (*note Invoking Bison:
  396. Invocation.).  This file shows the meaning of each state in terms of
  397. positions in various rules, and also what each state will do with each
  398. possible input token.  As you read the successive trace messages, you
  399. can see that the parser is functioning according to its specification
  400. in the listing file.  Eventually you will arrive at the place where
  401. something undesirable happens, and you will see which parts of the
  402. grammar are to blame.
  403.    The parser file is a C program and you can use C debuggers on it,
  404. but it's not easy to interpret what it is doing.  The parser function
  405. is a finite-state machine interpreter, and aside from the actions it
  406. executes the same code over and over.  Only the values of variables
  407. show where in the grammar it is working.
  408.    The debugging information normally gives the token type of each token
  409. read, but not its semantic value.  You can optionally define a macro
  410. named `YYPRINT' to provide a way to print the value.  If you define
  411. `YYPRINT', it should take three arguments.  The parser will pass a
  412. standard I/O stream, the numeric code for the token type, and the token
  413. value (from `yylval').
  414.    Here is an example of `YYPRINT' suitable for the multi-function
  415. calculator (*note Declarations for `mfcalc': Mfcalc Decl.):
  416.      #define YYPRINT(file, type, value)   yyprint (file, type, value)
  417.      
  418.      static void
  419.      yyprint (file, type, value)
  420.           FILE *file;
  421.           int type;
  422.           YYSTYPE value;
  423.      {
  424.        if (type == VAR)
  425.          fprintf (file, " %s", value.tptr->name);
  426.        else if (type == NUM)
  427.          fprintf (file, " %d", value.val);
  428.      }
  429. File: bison.info,  Node: Invocation,  Next: Table of Symbols,  Prev: Debugging,  Up: Top
  430. Invoking Bison
  431. **************
  432.    The usual way to invoke Bison is as follows:
  433.      bison INFILE
  434.    Here INFILE is the grammar file name, which usually ends in `.y'.
  435. The parser file's name is made by replacing the `.y' with `.tab.c'.
  436. Thus, the `bison foo.y' filename yields `foo.tab.c', and the `bison
  437. hack/foo.y' filename yields `hack/foo.tab.c'.
  438. * Menu:
  439. * Bison Options::     All the options described in detail,
  440.             in alphabetical order by short options.
  441. * Option Cross Key::  Alphabetical list of long options.
  442. * VMS Invocation::    Bison command syntax on VMS.
  443. File: bison.info,  Node: Bison Options,  Next: Option Cross Key,  Up: Invocation
  444. Bison Options
  445. =============
  446.    Bison supports both traditional single-letter options and mnemonic
  447. long option names.  Long option names are indicated with `--' instead of
  448. `-'.  Abbreviations for option names are allowed as long as they are
  449. unique.  When a long option takes an argument, like `--file-prefix',
  450. connect the option name and the argument with `='.
  451.    Here is a list of options that can be used with Bison, alphabetized
  452. by short option.  It is followed by a cross key alphabetized by long
  453. option.
  454. `-b FILE-PREFIX'
  455. `--file-prefix=PREFIX'
  456.      Specify a prefix to use for all Bison output file names.  The
  457.      names are chosen as if the input file were named `PREFIX.c'.
  458. `--defines'
  459.      Write an extra output file containing macro definitions for the
  460.      token type names defined in the grammar and the semantic value type
  461.      `YYSTYPE', as well as a few `extern' variable declarations.
  462.      If the parser output file is named `NAME.c' then this file is
  463.      named `NAME.h'.
  464.      This output file is essential if you wish to put the definition of
  465.      `yylex' in a separate source file, because `yylex' needs to be
  466.      able to refer to token type codes and the variable `yylval'.
  467.      *Note Semantic Values of Tokens: Token Values.
  468. `--no-lines'
  469.      Don't put any `#line' preprocessor commands in the parser file.
  470.      Ordinarily Bison puts them in the parser file so that the C
  471.      compiler and debuggers will associate errors with your source
  472.      file, the grammar file.  This option causes them to associate
  473.      errors with the parser file, treating it an independent source
  474.      file in its own right.
  475. `-o OUTFILE'
  476. `--output-file=OUTFILE'
  477.      Specify the name OUTFILE for the parser file.
  478.      The other output files' names are constructed from OUTFILE as
  479.      described under the `-v' and `-d' switches.
  480. `-p PREFIX'
  481. `--name-prefix=PREFIX'
  482.      Rename the external symbols used in the parser so that they start
  483.      with PREFIX instead of `yy'.  The precise list of symbols renamed
  484.      is `yyparse', `yylex', `yyerror', `yylval', `yychar' and `yydebug'.
  485.      For example, if you use `-p c', the names become `cparse', `clex',
  486.      and so on.
  487.      *Note Multiple Parsers in the Same Program: Multiple Parsers.
  488. `--debug'
  489.      Output a definition of the macro `YYDEBUG' into the parser file,
  490.      so that the debugging facilities are compiled.  *Note Debugging
  491.      Your Parser: Debugging.
  492. `--verbose'
  493.      Write an extra output file containing verbose descriptions of the
  494.      parser states and what is done for each type of look-ahead token in
  495.      that state.
  496.      This file also describes all the conflicts, both those resolved by
  497.      operator precedence and the unresolved ones.
  498.      The file's name is made by removing `.tab.c' or `.c' from the
  499.      parser output file name, and adding `.output' instead.
  500.      Therefore, if the input file is `foo.y', then the parser file is
  501.      called `foo.tab.c' by default.  As a consequence, the verbose
  502.      output file is called `foo.output'.
  503. `--version'
  504.      Print the version number of Bison.
  505. `--yacc'
  506. `--fixed-output-files'
  507.      Equivalent to `-o y.tab.c'; the parser output file is called
  508.      `y.tab.c', and the other outputs are called `y.output' and
  509.      `y.tab.h'.  The purpose of this switch is to imitate Yacc's output
  510.      file name conventions.  Thus, the following shell script can
  511.      substitute for Yacc:
  512.           bison -y $*
  513. File: bison.info,  Node: Option Cross Key,  Next: VMS Invocation,  Prev: Bison Options,  Up: Invocation
  514. Option Cross Key
  515. ================
  516.    Here is a list of options, alphabetized by long option, to help you
  517. find the corresponding short option.
  518.      --debug                               -t
  519.      --defines                             -d
  520.      --file-prefix=PREFIX                  -b FILE-PREFIX
  521.      --fixed-output-files --yacc           -y
  522.      --name-prefix                         -p
  523.      --no-lines                            -l
  524.      --output-file=OUTFILE                 -o OUTFILE
  525.      --verbose                             -v
  526.      --version                             -V
  527. File: bison.info,  Node: VMS Invocation,  Prev: Option Cross Key,  Up: Invocation
  528. Invoking Bison under VMS
  529. ========================
  530.    The command line syntax for Bison on VMS is a variant of the usual
  531. Bison command syntax--adapted to fit VMS conventions.
  532.    To find the VMS equivalent for any Bison option, start with the long
  533. option, and substitute a `/' for the leading `--', and substitute a `_'
  534. for each `-' in the name of the long option.  For example, the
  535. following invocation under VMS:
  536.      bison /debug/name_prefix=bar foo.y
  537. is equivalent to the following command under POSIX.
  538.      bison --debug --name-prefix=bar foo.y
  539.    The VMS file system does not permit filenames such as `foo.tab.c'.
  540. In the above example, the output file would instead be named
  541. `foo_tab.c'.
  542. File: bison.info,  Node: Table of Symbols,  Next: Glossary,  Prev: Invocation,  Up: Top
  543. Bison Symbols
  544. *************
  545. `error'
  546.      A token name reserved for error recovery.  This token may be used
  547.      in grammar rules so as to allow the Bison parser to recognize an
  548.      error in the grammar without halting the process.  In effect, a
  549.      sentence containing an error may be recognized as valid.  On a
  550.      parse error, the token `error' becomes the current look-ahead
  551.      token.  Actions corresponding to `error' are then executed, and
  552.      the look-ahead token is reset to the token that originally caused
  553.      the violation.  *Note Error Recovery::.
  554. `YYABORT'
  555.      Macro to pretend that an unrecoverable syntax error has occurred,
  556.      by making `yyparse' return 1 immediately.  The error reporting
  557.      function `yyerror' is not called.  *Note The Parser Function
  558.      `yyparse': Parser Function.
  559. `YYACCEPT'
  560.      Macro to pretend that a complete utterance of the language has been
  561.      read, by making `yyparse' return 0 immediately.  *Note The Parser
  562.      Function `yyparse': Parser Function.
  563. `YYBACKUP'
  564.      Macro to discard a value from the parser stack and fake a
  565.      look-ahead token.  *Note Special Features for Use in Actions:
  566.      Action Features.
  567. `YYERROR'
  568.      Macro to pretend that a syntax error has just been detected: call
  569.      `yyerror' and then perform normal error recovery if possible
  570.      (*note Error Recovery::.), or (if recovery is impossible) make
  571.      `yyparse' return 1.  *Note Error Recovery::.
  572. `YYERROR_VERBOSE'
  573.      Macro that you define with `#define' in the Bison declarations
  574.      section to request verbose, specific error message strings when
  575.      `yyerror' is called.
  576. `YYINITDEPTH'
  577.      Macro for specifying the initial size of the parser stack.  *Note
  578.      Stack Overflow::.
  579. `YYLTYPE'
  580.      Macro for the data type of `yylloc'; a structure with four
  581.      members.  *Note Textual Positions of Tokens: Token Positions.
  582. `YYMAXDEPTH'
  583.      Macro for specifying the maximum size of the parser stack.  *Note
  584.      Stack Overflow::.
  585. `YYRECOVERING'
  586.      Macro whose value indicates whether the parser is recovering from a
  587.      syntax error.  *Note Special Features for Use in Actions: Action
  588.      Features.
  589. `YYSTYPE'
  590.      Macro for the data type of semantic values; `int' by default.
  591.      *Note Data Types of Semantic Values: Value Type.
  592. `yychar'
  593.      External integer variable that contains the integer value of the
  594.      current look-ahead token.  (In a pure parser, it is a local
  595.      variable within `yyparse'.)  Error-recovery rule actions may
  596.      examine this variable.  *Note Special Features for Use in Actions:
  597.      Action Features.
  598. `yyclearin'
  599.      Macro used in error-recovery rule actions.  It clears the previous
  600.      look-ahead token.  *Note Error Recovery::.
  601. `yydebug'
  602.      External integer variable set to zero by default.  If `yydebug' is
  603.      given a nonzero value, the parser will output information on input
  604.      symbols and parser action.  *Note Debugging Your Parser: Debugging.
  605. `yyerrok'
  606.      Macro to cause parser to recover immediately to its normal mode
  607.      after a parse error.  *Note Error Recovery::.
  608. `yyerror'
  609.      User-supplied function to be called by `yyparse' on error.  The
  610.      function receives one argument, a pointer to a character string
  611.      containing an error message.  *Note The Error Reporting Function
  612.      `yyerror': Error Reporting.
  613. `yylex'
  614.      User-supplied lexical analyzer function, called with no arguments
  615.      to get the next token.  *Note The Lexical Analyzer Function
  616.      `yylex': Lexical.
  617. `yylval'
  618.      External variable in which `yylex' should place the semantic value
  619.      associated with a token.  (In a pure parser, it is a local
  620.      variable within `yyparse', and its address is passed to `yylex'.)
  621.      *Note Semantic Values of Tokens: Token Values.
  622. `yylloc'
  623.      External variable in which `yylex' should place the line and
  624.      column numbers associated with a token.  (In a pure parser, it is a
  625.      local variable within `yyparse', and its address is passed to
  626.      `yylex'.)  You can ignore this variable if you don't use the `@'
  627.      feature in the grammar actions.  *Note Textual Positions of
  628.      Tokens: Token Positions.
  629. `yynerrs'
  630.      Global variable which Bison increments each time there is a parse
  631.      error.  (In a pure parser, it is a local variable within
  632.      `yyparse'.)  *Note The Error Reporting Function `yyerror': Error
  633.      Reporting.
  634. `yyparse'
  635.      The parser function produced by Bison; call this function to start
  636.      parsing.  *Note The Parser Function `yyparse': Parser Function.
  637. `%left'
  638.      Bison declaration to assign left associativity to token(s).  *Note
  639.      Operator Precedence: Precedence Decl.
  640. `%nonassoc'
  641.      Bison declaration to assign nonassociativity to token(s).  *Note
  642.      Operator Precedence: Precedence Decl.
  643. `%prec'
  644.      Bison declaration to assign a precedence to a specific rule.
  645.      *Note Context-Dependent Precedence: Contextual Precedence.
  646. `%pure_parser'
  647.      Bison declaration to request a pure (reentrant) parser.  *Note A
  648.      Pure (Reentrant) Parser: Pure Decl.
  649. `%right'
  650.      Bison declaration to assign right associativity to token(s).
  651.      *Note Operator Precedence: Precedence Decl.
  652. `%start'
  653.      Bison declaration to specify the start symbol.  *Note The
  654.      Start-Symbol: Start Decl.
  655. `%token'
  656.      Bison declaration to declare token(s) without specifying
  657.      precedence.  *Note Token Type Names: Token Decl.
  658. `%type'
  659.      Bison declaration to declare nonterminals.  *Note Nonterminal
  660.      Symbols: Type Decl.
  661. `%union'
  662.      Bison declaration to specify several possible data types for
  663.      semantic values.  *Note The Collection of Value Types: Union Decl.
  664.    These are the punctuation and delimiters used in Bison input:
  665.      Delimiter used to separate the grammar rule section from the Bison
  666.      declarations section or the additional C code section.  *Note The
  667.      Overall Layout of a Bison Grammar: Grammar Layout.
  668. `%{ %}'
  669.      All code listed between `%{' and `%}' is copied directly to the
  670.      output file uninterpreted.  Such code forms the "C declarations"
  671.      section of the input file.  *Note Outline of a Bison Grammar:
  672.      Grammar Outline.
  673. `/*...*/'
  674.      Comment delimiters, as in C.
  675.      Separates a rule's result from its components.  *Note Syntax of
  676.      Grammar Rules: Rules.
  677.      Terminates a rule.  *Note Syntax of Grammar Rules: Rules.
  678.      Separates alternate rules for the same result nonterminal.  *Note
  679.      Syntax of Grammar Rules: Rules.
  680. File: bison.info,  Node: Glossary,  Next: Index,  Prev: Table of Symbols,  Up: Top
  681. Glossary
  682. ********
  683. Backus-Naur Form (BNF)
  684.      Formal method of specifying context-free grammars.  BNF was first
  685.      used in the `ALGOL-60' report, 1963.  *Note Languages and
  686.      Context-Free Grammars: Language and Grammar.
  687. Context-free grammars
  688.      Grammars specified as rules that can be applied regardless of
  689.      context.  Thus, if there is a rule which says that an integer can
  690.      be used as an expression, integers are allowed *anywhere* an
  691.      expression is permitted.  *Note Languages and Context-Free
  692.      Grammars: Language and Grammar.
  693. Dynamic allocation
  694.      Allocation of memory that occurs during execution, rather than at
  695.      compile time or on entry to a function.
  696. Empty string
  697.      Analogous to the empty set in set theory, the empty string is a
  698.      character string of length zero.
  699. Finite-state stack machine
  700.      A "machine" that has discrete states in which it is said to exist
  701.      at each instant in time.  As input to the machine is processed, the
  702.      machine moves from state to state as specified by the logic of the
  703.      machine.  In the case of the parser, the input is the language
  704.      being parsed, and the states correspond to various stages in the
  705.      grammar rules.  *Note The Bison Parser Algorithm: Algorithm.
  706. Grouping
  707.      A language construct that is (in general) grammatically divisible;
  708.      for example, `expression' or `declaration' in C.  *Note Languages
  709.      and Context-Free Grammars: Language and Grammar.
  710. Infix operator
  711.      An arithmetic operator that is placed between the operands on
  712.      which it performs some operation.
  713. Input stream
  714.      A continuous flow of data between devices or programs.
  715. Language construct
  716.      One of the typical usage schemas of the language.  For example,
  717.      one of the constructs of the C language is the `if' statement.
  718.      *Note Languages and Context-Free Grammars: Language and Grammar.
  719. Left associativity
  720.      Operators having left associativity are analyzed from left to
  721.      right: `a+b+c' first computes `a+b' and then combines with `c'.
  722.      *Note Operator Precedence: Precedence.
  723. Left recursion
  724.      A rule whose result symbol is also its first component symbol; for
  725.      example, `expseq1 : expseq1 ',' exp;'.  *Note Recursive Rules:
  726.      Recursion.
  727. Left-to-right parsing
  728.      Parsing a sentence of a language by analyzing it token by token
  729.      from left to right.  *Note The Bison Parser Algorithm: Algorithm.
  730. Lexical analyzer (scanner)
  731.      A function that reads an input stream and returns tokens one by
  732.      one.  *Note The Lexical Analyzer Function `yylex': Lexical.
  733. Lexical tie-in
  734.      A flag, set by actions in the grammar rules, which alters the way
  735.      tokens are parsed.  *Note Lexical Tie-ins::.
  736. Look-ahead token
  737.      A token already read but not yet shifted.  *Note Look-Ahead
  738.      Tokens: Look-Ahead.
  739. LALR(1)
  740.      The class of context-free grammars that Bison (like most other
  741.      parser generators) can handle; a subset of LR(1).  *Note
  742.      Mysterious Reduce/Reduce Conflicts: Mystery Conflicts.
  743. LR(1)
  744.      The class of context-free grammars in which at most one token of
  745.      look-ahead is needed to disambiguate the parsing of any piece of
  746.      input.
  747. Nonterminal symbol
  748.      A grammar symbol standing for a grammatical construct that can be
  749.      expressed through rules in terms of smaller constructs; in other
  750.      words, a construct that is not a token.  *Note Symbols::.
  751. Parse error
  752.      An error encountered during parsing of an input stream due to
  753.      invalid syntax.  *Note Error Recovery::.
  754. Parser
  755.      A function that recognizes valid sentences of a language by
  756.      analyzing the syntax structure of a set of tokens passed to it
  757.      from a lexical analyzer.
  758. Postfix operator
  759.      An arithmetic operator that is placed after the operands upon
  760.      which it performs some operation.
  761. Reduction
  762.      Replacing a string of nonterminals and/or terminals with a single
  763.      nonterminal, according to a grammar rule.  *Note The Bison Parser
  764.      Algorithm: Algorithm.
  765. Reentrant
  766.      A reentrant subprogram is a subprogram which can be in invoked any
  767.      number of times in parallel, without interference between the
  768.      various invocations.  *Note A Pure (Reentrant) Parser: Pure Decl.
  769. Reverse polish notation
  770.      A language in which all operators are postfix operators.
  771. Right recursion
  772.      A rule whose result symbol is also its last component symbol; for
  773.      example, `expseq1: exp ',' expseq1;'.  *Note Recursive Rules:
  774.      Recursion.
  775. Semantics
  776.      In computer languages, the semantics are specified by the actions
  777.      taken for each instance of the language, i.e., the meaning of each
  778.      statement.  *Note Defining Language Semantics: Semantics.
  779. Shift
  780.      A parser is said to shift when it makes the choice of analyzing
  781.      further input from the stream rather than reducing immediately some
  782.      already-recognized rule.  *Note The Bison Parser Algorithm:
  783.      Algorithm.
  784. Single-character literal
  785.      A single character that is recognized and interpreted as is.
  786.      *Note From Formal Rules to Bison Input: Grammar in Bison.
  787. Start symbol
  788.      The nonterminal symbol that stands for a complete valid utterance
  789.      in the language being parsed.  The start symbol is usually listed
  790.      as the first nonterminal symbol in a language specification.
  791.      *Note The Start-Symbol: Start Decl.
  792. Symbol table
  793.      A data structure where symbol names and associated data are stored
  794.      during parsing to allow for recognition and use of existing
  795.      information in repeated uses of a symbol.  *Note Multi-function
  796.      Calc::.
  797. Token
  798.      A basic, grammatically indivisible unit of a language.  The symbol
  799.      that describes a token in the grammar is a terminal symbol.  The
  800.      input of the Bison parser is a stream of tokens which comes from
  801.      the lexical analyzer.  *Note Symbols::.
  802. Terminal symbol
  803.      A grammar symbol that has no rules in the grammar and therefore is
  804.      grammatically indivisible.  The piece of text it represents is a
  805.      token.  *Note Languages and Context-Free Grammars: Language and
  806.      Grammar.
  807. File: bison.info,  Node: Index,  Prev: Glossary,  Up: Top
  808. Index
  809. *****
  810. * Menu:
  811. * $$:                                   Actions.
  812. * $N:                                   Actions.
  813. * %expect:                              Expect Decl.
  814. * %left:                                Using Precedence.
  815. * %nonassoc:                            Using Precedence.
  816. * %prec:                                Contextual Precedence.
  817. * %pure_parser:                         Pure Decl.
  818. * %right:                               Using Precedence.
  819. * %start:                               Start Decl.
  820. * %token:                               Token Decl.
  821. * %type:                                Type Decl.
  822. * %union:                               Union Decl.
  823. * @N:                                   Action Features.
  824. * calc:                                 Infix Calc.
  825. * else, dangling:                       Shift/Reduce.
  826. * mfcalc:                               Multi-function Calc.
  827. * rpcalc:                               RPN Calc.
  828. * action:                               Actions.
  829. * action data types:                    Action Types.
  830. * action features summary:              Action Features.
  831. * actions in mid-rule:                  Mid-Rule Actions.
  832. * actions, semantic:                    Semantic Actions.
  833. * additional C code section:            C Code.
  834. * algorithm of parser:                  Algorithm.
  835. * associativity:                        Why Precedence.
  836. * Backus-Naur form:                     Language and Grammar.
  837. * Bison declaration summary:            Decl Summary.
  838. * Bison declarations:                   Declarations.
  839. * Bison declarations (introduction):    Bison Declarations.
  840. * Bison grammar:                        Grammar in Bison.
  841. * Bison invocation:                     Invocation.
  842. * Bison parser:                         Bison Parser.
  843. * Bison parser algorithm:               Algorithm.
  844. * Bison symbols, table of:              Table of Symbols.
  845. * Bison utility:                        Bison Parser.
  846. * BNF:                                  Language and Grammar.
  847. * C code, section for additional:       C Code.
  848. * C declarations section:               C Declarations.
  849. * C-language interface:                 Interface.
  850. * calculator, infix notation:           Infix Calc.
  851. * calculator, multi-function:           Multi-function Calc.
  852. * calculator, simple:                   RPN Calc.
  853. * character token:                      Symbols.
  854. * compiling the parser:                 Rpcalc Compile.
  855. * conflicts:                            Shift/Reduce.
  856. * conflicts, reduce/reduce:             Reduce/Reduce.
  857. * conflicts, suppressing warnings of:   Expect Decl.
  858. * context-dependent precedence:         Contextual Precedence.
  859. * context-free grammar:                 Language and Grammar.
  860. * controlling function:                 Rpcalc Main.
  861. * dangling else:                        Shift/Reduce.
  862. * data types in actions:                Action Types.
  863. * data types of semantic values:        Value Type.
  864. * debugging:                            Debugging.
  865. * declaration summary:                  Decl Summary.
  866. * declarations, Bison:                  Declarations.
  867. * declarations, Bison (introduction):   Bison Declarations.
  868. * declarations, C:                      C Declarations.
  869. * declaring operator precedence:        Precedence Decl.
  870. * declaring the start symbol:           Start Decl.
  871. * declaring token type names:           Token Decl.
  872. * declaring value types:                Union Decl.
  873. * declaring value types, nonterminals:  Type Decl.
  874. * default action:                       Actions.
  875. * default data type:                    Value Type.
  876. * default stack limit:                  Stack Overflow.
  877. * default start symbol:                 Start Decl.
  878. * defining language semantics:          Semantics.
  879. * error:                                Error Recovery.
  880. * error recovery:                       Error Recovery.
  881. * error recovery, simple:               Simple Error Recovery.
  882. * error reporting function:             Error Reporting.
  883. * error reporting routine:              Rpcalc Error.
  884. * examples, simple:                     Examples.
  885. * exercises:                            Exercises.
  886. * file format:                          Grammar Layout.
  887. * finite-state machine:                 Parser States.
  888. * formal grammar:                       Grammar in Bison.
  889. * format of grammar file:               Grammar Layout.
  890. * glossary:                             Glossary.
  891. * grammar file:                         Grammar Layout.
  892. * grammar rule syntax:                  Rules.
  893. * grammar rules section:                Grammar Rules.
  894. * grammar, Bison:                       Grammar in Bison.
  895. * grammar, context-free:                Language and Grammar.
  896. * grouping, syntactic:                  Language and Grammar.
  897. * infix notation calculator:            Infix Calc.
  898. * interface:                            Interface.
  899. * introduction:                         Introduction.
  900. * invoking Bison:                       Invocation.
  901. * invoking Bison under VMS:             VMS Invocation.
  902. * LALR(1):                              Mystery Conflicts.
  903. * language semantics, defining:         Semantics.
  904. * layout of Bison grammar:              Grammar Layout.
  905. * left recursion:                       Recursion.
  906. * lexical analyzer:                     Lexical.
  907. * lexical analyzer, purpose:            Bison Parser.
  908. * lexical analyzer, writing:            Rpcalc Lexer.
  909. * lexical tie-in:                       Lexical Tie-ins.
  910. * literal token:                        Symbols.
  911. * look-ahead token:                     Look-Ahead.
  912. * LR(1):                                Mystery Conflicts.
  913. * main function in simple example:      Rpcalc Main.
  914. * mid-rule actions:                     Mid-Rule Actions.
  915. * multi-function calculator:            Multi-function Calc.
  916. * mutual recursion:                     Recursion.
  917. * nonterminal symbol:                   Symbols.
  918. * operator precedence:                  Precedence.
  919. * operator precedence, declaring:       Precedence Decl.
  920. * options for invoking Bison:           Invocation.
  921. * overflow of parser stack:             Stack Overflow.
  922. * parse error:                          Error Reporting.
  923. * parser:                               Bison Parser.
  924. * parser stack:                         Algorithm.
  925. * parser stack overflow:                Stack Overflow.
  926. * parser state:                         Parser States.
  927. * polish notation calculator:           RPN Calc.
  928. * precedence declarations:              Precedence Decl.
  929. * precedence of operators:              Precedence.
  930. * precedence, context-dependent:        Contextual Precedence.
  931. * precedence, unary operator:           Contextual Precedence.
  932. * preventing warnings about conflicts:  Expect Decl.
  933. * pure parser:                          Pure Decl.
  934. * recovery from errors:                 Error Recovery.
  935. * recursive rule:                       Recursion.
  936. * reduce/reduce conflict:               Reduce/Reduce.
  937. * reduction:                            Algorithm.
  938. * reentrant parser:                     Pure Decl.
  939. * reverse polish notation:              RPN Calc.
  940. * right recursion:                      Recursion.
  941. * rule syntax:                          Rules.
  942. * rules section for grammar:            Grammar Rules.
  943. * running Bison (introduction):         Rpcalc Gen.
  944. * semantic actions:                     Semantic Actions.
  945. * semantic value:                       Semantic Values.
  946. * semantic value type:                  Value Type.
  947. * shift/reduce conflicts:               Shift/Reduce.
  948. * shifting:                             Algorithm.
  949. * simple examples:                      Examples.
  950. * single-character literal:             Symbols.
  951. * stack overflow:                       Stack Overflow.
  952. * stack, parser:                        Algorithm.
  953. * stages in using Bison:                Stages.
  954. * start symbol:                         Language and Grammar.
  955. * start symbol, declaring:              Start Decl.
  956. * state (of parser):                    Parser States.
  957. * summary, action features:             Action Features.
  958. * summary, Bison declaration:           Decl Summary.
  959. * suppressing conflict warnings:        Expect Decl.
  960. * symbol:                               Symbols.
  961. * symbol table example:                 Mfcalc Symtab.
  962. * symbols (abstract):                   Language and Grammar.
  963. * symbols in Bison, table of:           Table of Symbols.
  964. * syntactic grouping:                   Language and Grammar.
  965. * syntax error:                         Error Reporting.
  966. * syntax of grammar rules:              Rules.
  967. * terminal symbol:                      Symbols.
  968. * token:                                Language and Grammar.
  969. * token type:                           Symbols.
  970. * token type names, declaring:          Token Decl.
  971. * tracing the parser:                   Debugging.
  972. * unary operator precedence:            Contextual Precedence.
  973. * using Bison:                          Stages.
  974. * value type, semantic:                 Value Type.
  975. * value types, declaring:               Union Decl.
  976. * value types, nonterminals, declaring: Type Decl.
  977. * value, semantic:                      Semantic Values.
  978. * VMS:                                  VMS Invocation.
  979. * warnings, preventing:                 Expect Decl.
  980. * writing a lexical analyzer:           Rpcalc Lexer.
  981. * YYABORT:                              Parser Function.
  982. * YYACCEPT:                             Parser Function.
  983. * YYBACKUP:                             Action Features.
  984. * yychar:                               Look-Ahead.
  985. * yyclearin:                            Error Recovery.
  986. * YYDEBUG:                              Debugging.
  987. * yydebug:                              Debugging.
  988. * YYEMPTY:                              Action Features.
  989. * yyerrok:                              Error Recovery.
  990. * YYERROR:                              Action Features.
  991. * yyerror:                              Error Reporting.
  992. * YYERROR_VERBOSE:                      Error Reporting.
  993. * YYINITDEPTH:                          Stack Overflow.
  994. * yylex:                                Lexical.
  995. * yylloc:                               Token Positions.
  996. * YYLTYPE:                              Token Positions.
  997. * yylval:                               Token Values.
  998. * YYMAXDEPTH:                           Stack Overflow.
  999. * yynerrs:                              Error Reporting.
  1000. * yyparse:                              Parser Function.
  1001. * YYPRINT:                              Debugging.
  1002. * YYRECOVERING:                         Error Recovery.
  1003. * |:                                    Rules.
  1004.